Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid access of front element in empty vectors #119

Merged
merged 4 commits into from
Jun 19, 2020
Merged

Avoid access of front element in empty vectors #119

merged 4 commits into from
Jun 19, 2020

Conversation

fweik
Copy link
Contributor

@fweik fweik commented Jun 10, 2020

There are multiple places in the library where a pointer to the memory managed by a vector by taking the address of the first element. This leads to undefined behavior if the vector is empty (eg there is no first element), which has caused problems downstream. For example some standard libraries have asserts for this. This patch is a modified version of a patch created by @mkuron which switches all the places that we found to detail::c_data, which already existed in the library.

(Please note that not all of the replacements are needed because in some places the vector can not
be empty, but I find the function call also more idiomatic and readable, and easier to replace when support for C++03 is dropped)

@mkuron
Copy link
Contributor

mkuron commented Jun 10, 2020

Just want to mention that this patch makes lots more places in Boost.MPI benefit from the fix introduced in #81.

@jngrad
Copy link

jngrad commented Jun 10, 2020

I can confirm this PR fixes the assertion error blocking 1843105 on Fedora 33 for OpenMPI & MPICH.

@pdimov
Copy link
Member

pdimov commented Jun 11, 2020

A test hangs, which is why the jobs time out; splitting them doesn't help with that. Add -l 240 to the b2 invocation (timeout in seconds, may need to vary the 240 appropriately, I'm not sure how long the tests normally take) to see which test.


namespace boost { namespace mpi {

namespace {
template <typename T, typename A>
T* c_data(std::vector<T,A>& v) { return &(v[0]); }
T* c_data(std::vector<T,A>& v) { return c_data(v); }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this going to call itself recursively forever?

Suggested change
T* c_data(std::vector<T,A>& v) { return c_data(v); }
T* c_data(std::vector<T,A>& v) { return detail::c_data(v); }

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be simpler just to replace this function with using detail::c_data;

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this going to call itself recursively forever?

A legitimate concern.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This not a recursive call, it's boost::mpi::<anonymous namespace>::c_data calling boost::mpi::detail::c_data. But I'll remove the former.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How is it going to call detail::c_data? Name lookup inside the function finds that function itself, not one that isn't even visible.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah sorry, I confused your suggested change with the diff. You are right of course.

@fweik
Copy link
Contributor Author

fweik commented Jun 11, 2020

The timeout were there before, e.g. #117 and all the other open PRs. Unfortunately there is no easy way to run the tests locally, so I think it's to cumbersome for me to debug this.

@fweik
Copy link
Contributor Author

fweik commented Jun 11, 2020

Let me know if I should revert 1b2b7bb...

@aminiussi
Copy link
Member

aminiussi commented Jun 19, 2020

Let me know if I should revert 1b2b7bb...

I'll merge that one individually

Thanks

@aminiussi aminiussi merged commit d9f0628 into boostorg:develop Jun 19, 2020
@aminiussi
Copy link
Member

A test hangs, which is why the jobs time out; splitting them doesn't help with that. Add -l 240 to the b2 invocation (timeout in seconds, may need to vary the 240 appropriately, I'm not sure how long the tests normally take) to see which test.

Can't reproduce: I've got all test passing on OpenMPI 4.0.0 and 4.0.4 (g++7.5.0) and Intel's 2020 compiler and MPI.

And none of them took that long.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants